Netware Super Library

home *** CD-ROM | disk | FTP | other *** search

/ Netware Super Library / Netware Super Library.iso / app_note / an106a / an106-1

Wrap

Text File | 1991-05-30 | 37.2 KB | 903 lines

Measuring Performance in the Extended Print Service Environment Rich Lee Senior Consultant Systems Engineering Division Abstract: NetWare print services can be configured for both simple and complex LAN printing environments. After reviewing several concerns from the low#end environment, this AppNote focuses on complex printing environments where many users send jobs to a single print queue. It discusses the issues involved in high#end printing environments and presents the results of some print service performance tests in these environments. LAN designers and managers will find several new techniques for predicting printing performance across the LAN. Disclaimer Novell, Inc. makes no representations or warranties with respect to the contents or use of these Application Notes (AppNotes) or of any of the third#party products discussed in the AppNotes. Novell reserves the right to revise these AppNotes and to make changes in their content at any time, without obligation to notify any person or entity of such revisions or changes. These AppNotes do not constitute an endorsement of the third#party product or products that were tested. Configuration(s) tested or described may or may not be the only available solution. Any test is not a determination of product quality or correctness, nor does it ensure compliance with any federal, state or local requirements. Novell does not warranty products except as stated in applicable Novell product warranties or license agreements. Copyright { 1991 by Novell, Inc., Provo, Utah. All rights reserved. As a means of promoting NetWare AppNotes, Novell grants you without charge the right to reproduce, distribute and use copies of the AppNotes, provided you do not receive any payment, commercial benefit or other consideration for the reproduction or distribution, or change any copyright notices appearing on or in the document. Contents Introduction 5 What Are Extended Print Services? 5 Why Study Extended Print Services? 5 Review of the Low#End Printing Environment 6 The Low#End Printing Model 6 Measuring Time Required to Print 7 Production Rates for Low#End Printing 8 The Effect of Network Awareness 9 The High-End Printing Environment 9 The High#End Printing Model 9 Number of Users per Printer 10 More Than One Job in the Queue 10 Measuring Print Time with Multiple Print Jobs 11 Defining the Dependent Variables 12 Isolating Application Adding Time 13 Extended Print Service Performance Tests 14 Basic Hardware Configuration 14 What We Measured and Why 14 Parameters for Calculation 15 Start Time 15 Dwell Time 15 Adding Time 16 Activation Time 16 Throughput Time 16 Clear Time 17 Print Time 17 Observations and Test Conclusions 17 Implementation Considerations 19 Calculating Average Queue Utilization 19 Probability Modeling 20 Appendix A: Test Results for Extended Print Services 22 Appendix B: High#End Test Configurations 23 Introduction This Application Note is a follow#up to the information in the #NetWare Print Service Performance" AppNote published in April 1991. Whereas that AppNote dealt with measuring print service performance in the low#end printing environment, this AppNote looks at the issues connected with measuring performance in the high#end or #extended" printing environment. It reviews the basic concepts of the low#end printing model, then discusses the variables that must be considered in the high#end printing model. After explaining the test methodology for extended print services, it presents some formulas that can be used in calculating average queue utilization and probability modeling. What Are Extended Print Services? For our purposes, we will define the ground of extended print services as follows: Any situation in which there is more than one job in the print queue at a time is an extended print service##or, more accurately, extends the print service. Basic to the understanding of extended print services is that there is no additional supporting software with which you extend your print services. Rather, the way you implement applications and hardware configurations extends your need for print services beyond the low#end printing environment of one job in one queue. In the extended printing environment, the print service and queue management functions do not become active and then go inactive with each print job. There are jobs to process beyond the current one. These other jobs in the queue extend (by time and job) print service activity; hence, #extended" print services. Why Study Extended Print Services? Even in low#end printing there can be periods of high usage which look, for the short term, very much like high#end. There are studies which indicate that even the most innocuous low#end environment may become a veritable torrent of printing activity, due more to human nature than to technical variables. (We'll look more closely at this phenomenon in a future AppNote.) Because of the potential intersection of low#end and high#end printing, even the low#end environment may present the LAN supervisor with difficulties normally encountered in high#end printing scenarios. What's more, users often get downright hostile when network printing slows down. For these reasons, the LAN supervisor should plan printing resources with the worst case in mind, or at least think through the ramifications for the maximum expected load. This can be hard to do, and may require gathering information from several sources. Hopefully the information in this AppNote will help. Review of the Low#End Printing Environment The #NetWare Print Service Performance" AppNote was concerned with measuring printing rate (in bytes per second) and production performance (in PPM and GPPM) in the low#end environment. It also dealt with determining what aspects of printing were production bottlenecks and calculating the throughput of the document to the printer. We measured delivery performance using Word Perfect 5.0 as our test application. We also briefly mentioned the difference between NetWare aware and unaware printing, and working around the CAPTURE command. In those studies, we came to several conclusions. Primarily, we saw that transmission rate is not a very useful measurement of printing performance. Rates can be misleading, especially with graphics output. Production performance at the printer is a far better measure of printing throughput. There were some other items of interest. Printing rates overall were slow, mainly because the applications just did not format and send the data rapidly. Printing at the printer was also slow, especially through serial ports. If all printing were done at the typical low#end rate of 2,242 bytes per second, high#end printing would suffer. The Low#End Printing Model All of this went to further our understanding of the low#end printing model, where print jobs must be added to a queue before the print redirection process can be attended to by the network print services. shows how we measured total print time in the low#end scenario (one job in the queue). : Low#end Printing Scenario Our definition of the low#end environment does not necessarily imply that you have a small number of users. It does imply that there is little network printing being done (because there is only one job in the queue at any given time.) However, the actual amount of setup and maintenance work is disproportionate to the amount of printing that takes place. A LAN supervisor defining print queues, printer definitions, and printer configurations cannot afford to maintain a high#end network using low#end options. Whereas a LAN supervisor in the low#end might define one queue for users and provide PRINTCON and PRINTDEF definitions for their individual needs, in the high#end a print queue might need to be designed for a particular type of printing (for instance, letterhead) and other queues might be set for other printer specific functions. Measuring Time Required to Print The essence of low#end printing is calculating how long it takes to print one job. This section gives a quick review of how this can be done. Production Rates for Low#End Printing lists typical production rates as determined in our low#end printing tests. These rates can be used in determining the time an application takes to produce a printed document. : Production Rates for Low#End Printing For example, if you want to know how long it would take to print a Graphics Only document in WordPerfect you'd need to know the production rate first. Referring to , you can use the following formula for calculating the approximate time to produce a completed document for a specific printer type: DOCUMENT SIZE (bytes) PRINT TIME (sec) = ----------------------------- (2-1) PRODUCTION RATE (bytes/sec) The variables in this formula are defined as follows: Document Size = Transmittable size of the document (in bytes) by document type Note that this is not the same as the size of the document as it is stored on disk. When you send a document to be printed, the size increases because of the additional information that is set to the printer. To see the difference, use CAPTURE CR = FileName TI=nn and observe the size of the resultant file. Production Rate = Bytes per second to transmit the document to the printer (from the table) Of course, you also need to know the printer port type (parallel or serial) and the document type (G/O, STR, T/G, or T/O) to do the calculation. The table only shows the rates for G/O documents sent to an HP PCL#5 printer through a parallel port. See the April AppNote for more complete tables. Remember also that the printable document size is computed from the printer output when the document is sent to the printer. The Effect of Network Awareness The rates shown above are for applications that have network#aware printing capabilities. Using the CAPTURE command to redirect local printing to the network decreases the rate and increases the time to print the document considerably. If you want to use an application that does not use network#aware printing, the increase in print time may or may not be a problem. However, you might contact the program's manufacturer and let them know how beneficial the addition of network#aware capabilities would be. This type of calculation for print time is useful only to someone in the low#end printing environment. Once you move into the high#end environment (with more than one job in the queue), the methods for calculating how quickly a job can be produced change drastically. The High-End Printing Environment Having reviewed the low#end printing environment, we are ready to pursue the next step of the printing series, which is to further divide the matrix to cover more complex situations. The High#End Printing Model The contrasts between the low#end and high#end of printing are mainly found in: w the relative organization of the print service structures (which print services are selected) w the reasons behind creating additional print queues (the problem you are trying to solve) w the quantity of print jobs (how much paper is used) w the frequency of print queue utilization (how many jobs are in the queue at a time) Admittedly, there are more ways of combining the above factors than any one article can deal with. We'll focus on print job quantity and the methodology used to redirect and complete those jobs. In the low#end there is occasionally quantity, but rarely the increased use of options to handle additional workload. In the high#end there is often a large quantity of print jobs, along with numerous options for handling the workload. In the high#end model, you have more queues, more users, and usually a longer period of time before all current jobs are done. To do any type of prediction on how long it will take to get a job printed, you must consider the following factors. Number of Users per Printer Determining how many people are using each printer is trickier than it seems. Often a printer has more than one queue sending work. You may have to account for users from different parts of the network before you can study the actual printer activity. The following is a rough formula that might help you: N = NP1Q1 + NP1Q2 + ... +NP1(Sn/Qn) (2-2) where N = Number of user for Printer #1 NP1Q1 = Number of users sending jobs to Printer #1 via Queue #1 NP1Q2 = Number of users sending jobs to Printer #1 via Queue #2 NP1(Sn/Qn) = Number of users sending jobs to Printer #1 via Queue n on Server n More Than One Job in the Queue The main difference between low#end and high#end printing is that in the high#end environment a second print job is already in the queue ready to be activated. In this case, the relationship in formula 2-1 relating printing time to the length of the document cannot be used. The total time to produce the document is now reliant to some degree upon the time in which other documents are finished at the printer. shows the events that must be measured to determine total time to print in the high#end environment. : High#end Printing Scenario The times labled T0 through T7 will be defined later in this AppNote. In , the three print jobs arrive in the queue at about the same time. shows other possibilities for how jobs can arrive in the queue. : Three Ways Multiple Jobs Can Arrive in the Queue Scenario #1 in resembles the low#end model. It is when print jobs start to overlap in the queue that we move into the high#end and measuring time to print becomes more difficult. Measuring Print Time with Multiple Print Jobs Now that we have covered some of the differences between low#end and high#end printing environments, we can examine how to measure performance in the high#end environment. In the low#end environment, we measured performance as the total time to print divided into the total pages printed: NUMBER OF PAGES PPM (pages/min) = -------------------- (2-3) TIME TO PRINT The time to print was measured from the job initiation (to) to the printing completion time (tn) when the last page came out of the printer. T (time to print) = tn # to (2-4) In the high#end, the time to print a document is influenced by the number of jobs ahead of the one you want to print: Total Time = T(job #1) + T(job #N) ... + T(your job) (2-5) This creates a difficulty for the designer or supervisor (not to mention the user) in that you must be able to predict the number of print jobs to determine the amount of hardware that must be allocated, to say nothing of the manpower required for preparation and implementation. It changes the environment to one where probabilities describe the time to print a document. Defining the Dependent Variables In working with extended print service performance, we need to define more terms. For our performance testing, we divided the observable print service functions into distinctly quantifiable parameters. Some of the parameters received names based upon a necessary measure; others were named from calculated test results. For instance, the time for a print job to be added to a queue was seen as distinctly different from the time to deliver it to the printer. This parameter was called the Queue Adding time. Each of the other distinct functions inherent to the print service function were looked at and named in a similar fashion. lists the dependent variables we identified : Dependent Variables for Measuring Extended Print Service Performance These variables are shown in . TESTDOC would be the job sent by User 1, and FINALDOC would be the job sent by User 2. We'll talk more about these variables later. Isolating Application Adding Time Defining these measurable quantities was not enough. We also had to determine if they had a function, what measuring them actually described in the system, and what print service was actually responsible for the performance measured. For instance, T2 (the Adding time) is the difference between t2 (the measured time) and to (the time at initiation). T2 = t2(time at Ready flag) # t0(time at start) (2-6) The resultant T2 is the absolute time from the start. The Adding time was the amount of time the application took to add the document to the queue and for the #Ready" flag to be produced in PCONSOLE. Observably, Adding times were longer for applications adding print jobs than for NPRINT to add to the queue. This made sense, since NPRINT sends already formatted printer#compatible output. We saw Adding time as a significant number for two other reasons. One, the first job in the queue would put its Adding time on in front of any other subsequently added job (that is, another job that is added before the first one clears or is sufficiently long to be adding when the first one is clear. Although different in detail, the instance looks much the same to the waiting users.) Two, different applications have different Adding times, but the Adding time becomes less significant as the job length increases. From our low#end study, we knew that the document type had a direct effect on the printer performance. In the area of high#end printing, we recognized that the document type would continue to have a marked effect on the queue Adding time and on the printer response time. We also knew that the printing port (parallel or serial) had some of the greatest effect upon printing performance. The questions we had were: w Will the limitations of the printing port dictate the amount of queue loading and (subsequently) the printing performance at the printer? w Will the printing rate from the queue to the printer be significantly high that jobs from the queue will drain out instead of build up? w Will the institution of alternate printers and services be necessary to maintain printing performance? These questions will have to be answered later. What we're ultimately aiming for is a formula or table which would be useful in predicting the time to receive print jobs in the high#end environment. At least this would be something to justify the purchase of another printer, and help in the future matter of how to maintain all of this as a LAN supervisor. Extended Print Service Performance Tests In designing our extended printing performance tests, we used two major operating systems: NetWare v2.2 and v3.11. The testing configurations were similar to the configurations tested in the low# end study, with the following differences: w the ports tested (only parallel, no serial) w the type of printers used (HPIII and HPIIIsi with its own network interface card) w the number of queues (some tests utilized two loaded queues) Basic Hardware Configuration shows our basic hardware configuration. As usual, all of the testing was done on thin Ethernet cable with NE2000 cards. Most of the testing revolved around manipulating the parameters and workloads in one configuration. : Basic Test Configuration What We Measured and Why In the testing regimen, our interest centered around times of delivery to anywhere and everywhere the print job was tracked before it was finished at the printer. Our interest in where the job went and how long it was there led us through the parts of NetWare printing we could measure and gave us some insight into what processes were taking how long in the printing environment. As mentioned before, we had decided to break the printing process into the major component parts that we could discriminate. From those we would try to discern what factors were pertinent in measuring the print services and which were extraneous. From , we were able to break print services into the following major components: Start time, Dwell time, Adding time, Activation time, Throughput time, Clear time, and Print time. Parameters for Calculation This section discusses derived values. The derived values are the result of subtracting the tn values discussed in the previous section. The resulting values have been assigned capital letters. The time formulas, or #T" formulas, provide us with several insights and a few questions which we do not have answers for yet. Start Time The first parameter is Start Time. In and of itself, it only marks the beginning of the test. However, it has become the basis by which we measure the absolute time of events on the printing side of the network. To = START TIME (2-7) Dwell Time The next item we will call Dwell time, until we come up with a more descriptive name. Dwell time is the interval between the start of a print job (user print initiation) and the time it actually starts being added to the queue. Note that we mean the time the Adding flag is set, not the time it actually appears in PCONSOLE. Ideally, this is what we would have liked to measure. But the lack of sophisticated#enough tools prevented it. What we measured was the time until the Adding flag appeared. T1 = DWELL TIME = t1 # t0 (2-8) The value of Dwell time is that it tells us the amount of time between the user initiating printing to the network and the time for the network to initiate the response that says #OK, adding job XYZ." That also includes formatting time for the application. So what value is there in measuring the Dwell variable? Probably more than just how long you have to wait for the PCONSOLE #Adding" message to come on. Actually, it tells you a lot about the application's ability to print immediately or wait for other processes. On a busy network (85 percent utilization), Dwell time does not appear to take any longer than on a 30 percent utilized network. That is one of the reasons we used NPRINT for our testing. It significantly reduced the wait for T1. (For now, Dwell time is a measurable number of questionable significance.) Adding Time Adding time is calculated in the same way as the Dwell time: T2 = ADDING TIME = t2 # t0 (2-9) This is the time it takes to get the #Ready" message in PCONSOLE, and represents the amount of time for the application to send the formatted data to the queue. Activation Time The Activation time is how long it takes to get the #Active" flag from PCONSOLE. At this point, everything is in the print queue and the print service has gone active to the printer. T3 = ACTIVATION TIME = t3 # t0 (2-10) Throughput Time One of the measurements taken which has not been evaluated thoroughly is the THRU time, the time for the first sheet to be printed. T4 = THRU TIME = t4 # t0 (2-11) This is probably a misnomer and the selection of using the first sheet from the printer is probably a mistake. That will have to wait for another set of tests to verify. What it should have measured (and at this point probably does not) is the effect on the print service of utilizing PRINTCON and PRINTDEF. It might provide some insight into the performance activity relation with and without those utilities. For now, the data was sampled without PRINTCON or PRINTDEF. Clear Time Next is the #Clear" time, which we define as the disappearance of the #Active" message from PCONSOLE. Interestingly enough, in all cases this corresponded to the NEXT JOB time that we were trying to obtain as a different measurement. The #Active" message appeared for the next print job in the queue just as the last job cleared. T5 = CLEAR TIME = t5 # t0 (2-12) Print Time The last measured time was when the final page of the print job came out of the printer. This Print time, as we dubbed it, was the time for the job to complete at the printer. T6 would be the time to use for calculating printing performance. T6 = PRINT TIME = t6 # t0 (2-13) Observations and Test Conclusions The results of our extended print services tests are given in Appendix A. We had the opportunity to make several observations during our testing regimen. As observations, they have to be qualified as such. They are not necessarily tested results, and may prove completely erroneous. One of the most interesting things we observed during the printing tests was the server utilization. During the server loading tests for the HPIII using the parallel port, the server utilization normally went from 50 percent (loaded) to 85 percent and then varied from 67 percent to 92 percent for the remainder of the printing process. When the HPIIIsi was tested under the same conditions, the server utilization went to 85 percent momentarily, dropped back to 50 percent (the load factor) for most of the print job, increased briefly to 70 percent, then returned to 50 percent. We were looking for some simple time measurements that indicated print job transmission rates across the network. We found just those, but with an interesting twist. When the parallel port was being tested, we could see the transmission rate of the parallel port was definitely affecting the production rate so that nothing was going to the printer faster than 1,799 bps. With the HPIIIsi, the transmission rate to the printer was higher. The results in show the comparison between NetWare v2.2 and v3.11 for parallel port HPIIIsi printing with regard to the t5 # t3 time. This brought up some question as to what effect replicating the experiment with a Graphics Only document would have, so we tested it as well. : Comparison of Rates with VAP and NLM Interestingly, the results for the HPIIIsi indicate that with the influence of the parallel port removed and the printer changed (between the HPIII and the HPIIIsi), the transmission rate from the queue to the paper was no longer a major limiting factor in print job production. A Graphics Only document moves through the queue almost as fast as a Text/Graphics document does. Implementation Considerations One of the major concerns in implementing extended print services is user convenience. The whole point of optimizing print services is to give the user as optimal a consideration as possible, while maintaining (if not optimizing) the ability to manage the activity and the network. Users bear the brunt of the work activity (#load"); the computer could care less. Over the years, users have increased their productivity, and now with the microcomputer being well established there is no reason to expect that productivity to decline. In fact, faster CPUs, better application software, and faster peripherals all precede an even greater surge in productivity. As we view users, we find that almost universally they become more proficient at whatever tasks they have. Printing is no exception. With all these increasingly productive software users printing, LAN services will have to improve. The areas of design, implementation, and supervision will all need sharper, faster tools. In the meantime, here are a few formulas which may not alter the shape of your LAN, but may provide just enough ammunition in the next planning meeting to get you the additional items you need. Calculating Average Queue Utilization One calculation that may prove very useful to the LAN supervisor is a simple but effective average of time the queue is utilized. T(App.Avg.(full)) + (N#1) T(Avg. Active) Avg. Printing Time = --------------------------- (2-14) N Note that (N#1), the number of people printing minus one, is not a subscript, but a multiplier. Here T(App.Avg.(full)) is equal to the average measured full time for an application to print through to the printer (assuming no queue priorities have been set). It must take into account all the types of print jobs that different types of users may send to that queue. If you want to determine this number, get a sampling of the documents used by a queue's workgroup for that queue specifically and print them out, one at a time. Then take the average. The result in formula 2-14 is the average time to complete printing for all of the users in a queue. You can expend a lot of work in determining this number, especially if individuals in the queue workgroup or queue#group are highly heterogeneous in their printing. But the result, especially for peak period printing, is extremely useful. It can tell you approximately how long the last person will wait for a print job in peak periods. It is up to the LAN supervisor or print manager to get with the users and work out a solution if this time is too long. How long is too long is something you will have to work out within your own workgroups and budget constraints. However, it does present the necessity for exploring some of the alternatives in print service design. Options you may wish to explore include: w multiple queues w multiple (existing or new) printers to a queue with user notification w high speed printers w consolidating several queues w changing the physical design of the printing workgroups Probability Modeling The next activity that may be of interest is calculating the probability of getting your own job through in a period of time. Using a typical example such as ten people, each with five print jobs to do by noon, usually gives the wrong result. This oversimplification does not take into consideration that the five print jobs are six#page contracts, that they are in revision two times, that they are printed for the individual with each revision, and that they all have to go out by noon. What this means is ten people will be printing those jobs twice between 11:00 a.m. and 11:45 a.m. That's 100 print jobs (fancifully the short ones are one page long) all to be printed in 45 minutes. Now suppose the print jobs are real estate letters and each one of them contains a graphic. It's going to take the ten users 1 second each to begin the printing cycle; unfortunately only one user can be first. The other nine will get their jobs in after the lucky first user. Several people are going to have to wait; the only question is who and for how long. Regarding the #who" question, you can always set the queue priority for several queues talking to one printer. This lets you get the chief executive's print job scheduled as number 2 with multiple queues to one printer, even when the job is sent as number 6. Having several queues talking to one printer gives our average time formula a bit of a twist, because the number N in the formula now has to take into consideration all of the queue#groups that talk to one printer. N = n (queue group #1) + ... + n (queue group #N) (2-15) With this value for N, it should not take longer for the last job to be printed than the average print time multiplied by the number of users. T(App.Avg.(full)) + (N#1) T(Avg. Active) Avg. Printing Time = ---------------------------- (2-16) N For peak period printing with printer contention from other queue#groups, the probability model for the priority 2 queue with a priority 1 queue attached begins to look like: (T(App.Avg.(full)) + T(Avg. Active Queue1)) x (N-2) + T(Avg. Active Queue2) Avg. Printing Time = --------------------------------------------------- (2-17) NToT For periods with no contention, it looks like: Avg. Printing Time = T(App. Avg. (full) Queue2) (2-18) Normally it should not take longer than the above average time for the non#priority job to get through the printer. Of course, you can take this type of modeling beyond its useful boundaries, but figuring your average print time does provide the groundwork for a discussion on when new printers may need to be added and what queues will have priority over the others. Appendix A: Test Results for Extended Print Services The following table lists the times recorded during the extended print service tests. The absolute times (ABS) indicate cumulative time from the initiation of the print job. The delta times represent the difference between each discrete measurement. For an explanation of the numbers in the #Test Config" column, see Appendix B. TEST ABS... DELTA. ABS... DELTA. ABS... DELTA. ABS... DELTA. ABS... DELTA. ABS... DELTA. CONFIG T1 T1 T2 T2 T3 T3 T4 T4 T5 T5 T6 T6 (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) ______ ______ ______ ______ ______ ______ ______ ______ ______ ______ ______ ______ 19 3 3 8 5 12 4 35 23 53 41 70 17 19 5 5 10 5 12 2 30 18 50 38 59 9 19 2 2 7 5 22 15 43 21 62 40 71 9 20 3 3 8 5 9 1 28 19 48 39 58 10 20 7 7 12 5 17 5 41 24 56 39 69 13 20 4 4 8 4 18 10 41 23 59 41 70 11 21 5 5 9 4 11 2 34 23 50 39 63 13 21 5 5 6 1 11 5 34 23 50 39 62 12 21 4 4 6 2 10 4 25 15 44 34 55 11 22 3 3 8 5 18 10 64 46 64 46 77 13 22 5 5 10 5 15 5 39 24 55 40 65 10 22 4 4 5 1 19 14 42 23 59 40 70 11 23 6 6 8 2 21 13 83 62 216 195 235 19 23 5 5 7 2 17 10 101 84 197 180 217 20 23 3 3 3 0 14 11 76 62 209 195 229 20 26 4 4 9 5 10 1 99 89 214 204 215 1 26 3 3 9 6 14 5 60 46 194 180 213 19 26 3 3 7 4 18 11 75 57 214 196 231 17 27 3 3 8 5 18 10 69 51 168 150 187 19 27 4 4 4 0 37 33 75 38 187 150 204 17 27 4 4 4 0 15 11 72 57 178 163 201 23 31 2 2 10 8 12 2 31 19 41 29 54 13 31 5 5 5 0 6 1 28 22 40 34 53 13 31 1 1 8 7 8 0 28 20 41 33 51 10 34 2 2 7 5 17 10 38 21 47 30 61 14 35 2 2 3 1 12 9 32 20 34 22 46 12 35 2 2 7 5 17 10 32 15 33 16 47 14 35 5 5 6 1 10 4 25 15 25 15 38 13 Appendix B: High#End Test Configurations This appendix details the hardware and software configurations (numbered 19 through 35) used for the extended print service performance tests. These are the numbers indicated in the #Test Config" column in Appendix A. Printer DOCUMENT N0. Type Config OS QUEUES LOAD PSERVER VERSION Size Type METHOD 19 HPIIIsi F/S 2.2 1 U VAP V1.21 270451 T/G NPRINT 20 HPIIIsi F/S 2.2 2 U VAP V1.21 270451 T/G NPRINT 21 HPIIIsi F/S 2.2 2 L VAP V1.21 270451 T/G NPRINT 22 HPIIIsi F/S 2.2 1 L VAP V1.21 270451 T/G NPRINT 23 HPIII F/S 2.2 1 U VAP V1.21 270451 T/G NPRINT 24 HPIII F/S 2.2 2 U VAP V1.21 270451 T/G NPRINT 25 HPIII F/S 2.2 2 L VAP V1.21 270451 T/G NPRINT 26 HPIII F/S 2.2 1 L VAP V1.21 270451 T/G NPRINT 27 HPIII F/S 3.1 1 U NLM V1.21 270451 T/G NPRINT 28 HPIII F/S 3.1 1 L NLM V1.21 270451 T/G NPRINT 29 HPIII F/S 3.1 2 L NLM V1.21 270451 T/G NPRINT 30 HPIII F/S 3.1 2 U NLM V1.21 270451 T/G NPRINT 31 HPIIIsi F/S 3.1 1 U NLM V1.21 270451 T/G NPRINT 32 HPIIIsi F/S 3.1 1 L NLM V1.21 270451 T/G NPRINT 33 HPIIIsi F/S 3.1 2 L NLM V1.21 270451 T/G NPRINT 34 HPIIIsi F/S 3.1 2 U NLM V1.21 270451 T/G NPRINT 35 HPIIIsi F/S 3.1 1 U NLM 1.21 150807 G/0 NPRINT Editor's Note: The author accepts written feedback at FAX (801) 429#5511.